Direct Anonymous Attestation Explained

Assume that the user a trusted computing platform communicates with a verifier who wants to be assured that the user indeed uses a platform that can be trusted. trusted hardware module, This problem is called remote attestation and discussed in detail in Chapter ??. As described there, the problem in the end boils down to the problem that a trusted platform module (TPM) needs to prove that the attestation identity key (AIK) it has generated was indeed generated by an authentic trusted platform module. In principle, the TPM could use its endorsement key (EK) together with its certificate on this key to authenticate the AIK. However, the user wants her privacy protected and therefore requires that the verifier only learns that she uses a TPM but not which particular one – thus such a solution does not work as all her transactions would become linkable to each other by the EK. Another solution to the problem could be using any standard public key authentication scheme (or signature scheme): One would generate a secret/public key pair, and then embed the secret key into each TPM. The verifier and the TPM would then run the authentication protocol. Because all TPMs use the same key, they are indistinguishable. However, this approach would never work in practice: as soon as one hardware module (TPM) gets compromised and the secret key extracted and published, verifiers can no longer distinguish between real TPMs and fake ones. Therefore, detection of rogue TPMs needs to be a further requirement. The solution first developed by TCG uses a trusted third party, the socalled privacy certification authority (Privacy CA), and works as follows [25]. Each TPM generates an RSA key pair called an Endorsement Key (EK).